fix(platform-objects): 21 zh-CN metadata-form leaves say what their source says - #16226

Fixes #14931

Twenty-one zh-CN metadataForms leaves in
packages/platform-objects/src/apps/translations/zh-CN.metadata-forms.generated.ts assert
something their English source does not, or drop a distinct concept it names. One line
each; the file's structure, its key set and its 158 byte-identical-to-en fills are
untouched.

Authored by Claude Code in session session_01ARYe3yQTQCUFm5qPYNgKaJ, dispatched on
issue #14931; the claim record is comment 5557212975 on that card.

Subtraction first — 21 of the enumerated 26, measured before any edit

The census on #14587 (comment 5524387962) enumerated 26 leaves. Five have already
landed, all in the dashboard subtree, all in one commit 9f57f1e31 (#14926). Both
bundles were flattened to dotted leaf paths at origin/main 9f3989771: 773 leaves
each, key sets identical, 158 byte-identical to en, 615 differing (the census read
767 / 154 / 613 — the bundle has gained six leaves since). Every one of the 26 was then
compared, by text, against that tree.

⚠️ dashboard.fields.gap.helpText, repaired by #16163, is not one of the 26 and does
not move the count. The remaining 21 are this PR, and every one still carried its
census value at 9f3989771.

⛔ The 18 looser paraphrases the census deliberately excluded are untouched, and so are
es-ES and ja-JP.

Grouped by defect kind, with the source quoted

A · Asserts an input or a concept that does not exist

• skill.sections.triggers holds exactly one field, triggerConditions
  (packages/spec/src/ai/skill.form.ts:35-42). triggerPhrases was removed with the key —
  the form's own comment records that phrases were never matched. 「触发关键词」 promised a
  keyword input that is not there.
• email_template.fields.variables — EmailTemplateDefinitionVariableSchema
  (packages/spec/src/system/email-template.zod.ts:37-42) declares name / type /
  required / description. There is no default value. The leaf promised
  「默认值」. The replacement follows the sibling email_template.fields.fromOverride.helpText,
  which is already 「示例：{ "name": "Acme Sales", … }」 — the bundle's own way of
  translating a helpText that IS a JSON literal.
• action.sections.advanced — bulkEnabled was removed from this section
  (packages/spec/src/ui/action.form.ts:81-82); it now holds ai, recordIdParam,
  recordIdField, bodyShape. 「批量」 named a control that is gone, while 「API 请求体结构」 —
  the exact phrase the bundle already uses at action.fields.bodyShape.label — was missing.
• page.sections.basics holds name, label, icon, type, template,
  description; 「名称、标题与图标」 enumerated three of six and dropped template, the one
  concept the source raises to section level. 「页面标识与模板」 mirrors the landed
  「仪表板标识与描述」.
• app.fields.defaultAgent — the source names no button and no screen position;
  「右下角浮动助手按钮」 invented both, and the 'ask' / 'build' defaults were missing.
  「环境助手」 is this bundle's own rendering of "ambient assistant"
  (app.sections.content.description), and 「智能体」 its own for "agent"
  (app.fields.defaultAgent.label).

B · Names the wrong technology

• action.fields.body told a zh author the body is JavaScript. An L1 expression is not
  JavaScript, and the L2 body is sandboxed. The replacement is verbatim the sibling
  hook.fields.body.helpText, which translates the identical source sentence correctly —
  ⛔ not a third phrasing invented here.
• page.fields.type carried a superseded enumeration (list / record / home / app / utility) that the source no longer names, and dropped the claim it does make — that
  "List / Interface" binds a source view into a curated surface. The option labels are not
  in this bundle, so the author sees List / Interface page in English; the quoted token is
  therefore kept in English too. The trailing sentence was already correct and is carried
  through unchanged.

C · Drops a distinct concept the source names

Two of these were saying something the code contradicts rather than merely saying less:
skill.fields.description claimed the field is what the AI reads to decide whether to
invoke the skill — the form's own comment records that routing is triggerConditions plus
the agent allowlist — and permission.fields.systemPermissions replaced "capability keys"
with a three-way categorisation the source never draws.

Word choices, argued against this bundle's own usage

Every replacement re-uses a term this bundle already uses for the same concept, rather than
a fresh one. Counts are over the 773 zh-CN leaves of this file.

Three calls needed a decision rather than a lookup, and are recorded as such:

• 「概述」 for "Summarize", not 「汇总」 or 「摘要」. 汇总 is already taken in this same
  bundle by roll-up aggregation (field.fields.summaryOperations.label 「汇总操作」), and
  摘要 is used elsewhere in the repo for messaging digests
  (service-messaging/src/translations/zh-CN.objects.generated.ts). Both would be false
  friends here.
• 「运算符」 for "operators" — zero in-repo precedent either way (运算符 and
  操作符 both return 0 hits across packages/, examples/); the standard term was taken.
• 「插值」 for "interpolation" — likewise zero in-repo precedent. The literal
  {{var.path}} token is kept verbatim, which is what actually tells the author what to type.

Punctuation register, measured, not assumed: 60 of the 66 translated section
descriptions in this file do not end in 。, and 205 of 212 translated helpTexts do not
either; the six that do are multi-sentence. Single-clause replacements here therefore carry
no trailing period, and the five multi-sentence ones do.

⛔ Every instrument here is blind to this class — the gates are reported, not claimed

check-i18n-stale-fill detects a leaf that is a byte copy of a previous source
revision, via cross-locale agreement or a recorded digest. These 615 legacy-trusted leaves
are neither, and the gate's own header states the general case: once a leaf differs from
current source, a stale fill is indistinguishable by value from a real translation. The
card proved this by ablation. ⇒ No green below is evidence that this change was needed or
that it worked. The acceptance evidence is the leaf-by-leaf table above.

Regeneration does not correct these either: bundle merge fills gaps only, and a
present-but-wrong leaf is not a gap.

Gate family — all 49 derived families, run at 7b890a69e

Derived with node scripts/pm/dispatch-gates.mjs --repo objectstack-ai/objectstack
(no hand-written path list): 40 named by path + 2 by change kind + 7 declared whole-tree.
All 49 exit 0. Exit codes were captured with redirect-then-read, never through a pipe.

Two returned exit 3 = PREREQUISITE NOT MET on the first pass — check:i18n (workspace
CLI not built) and check:dual-build-cjs-loads (packages without dist/). Those are
NOT MEASURED, not reds. Both prerequisites were then cleared with a real build and both
re-run green:

• check-i18n-bundles: OK (9 package(s) — all bundles in sync, no undeclared authoring keys).
• check:dual-build-cjs-loads — 103 published require entry point(s) across 66 package(s) load; 619 emitted CommonJS file(s) parse
• check-i18n-stale-fill: OK (10 bundle set(s) — no new stale fills, 0 baselined). · 27 provenance companions, 27 served, 0 unserved
• check-dts-closure: 57 built package(s) swept - 147/147 declared declaration file(s) present — and packages/platform-objects/dist is in that swept set (verified: the 8-package first pass was exactly the 8 directories carrying a dist/, platform-objects among them)

Package-level: @objectstack/platform-objects — 35 test files, 528 tests, all passing;
typecheck clean, and tsc --listFiles confirms the edited file is in that program
(1 hit), so the green is about this file rather than around it.

Repo-wide pnpm lint was narrowed, and the narrowing is measured rather than assumed:
(1) eslint --print-config on the edited file returns 6 configured rules, so it is in
eslint's own swept population; (2) --format json over the diff reports 2 files handed in,
1 actually linted (the changeset .md is "ignored because no matching configuration"),
0 errors, 0 warnings; (3) languageOptions.parserOptions.project and projectService
are both null — type-aware linting is not enabled, so editing string values in one
file cannot move the verdict on any untouched file; (4) instrument liveness — a control
file placed in the same directory under the same config produced 1 no-restricted-imports
error, so the zero above is a reading and not a silence.

Clause-② — no, and non-vacuously so

Measured by ablation at 7b890a69e, not asserted. @objectstack/platform-objects publishes
files: ["dist", …], so the published surface is all 66 files under dist/ — the whole
set was compared, ⛔ not the root barrel.

HEAD blob         69c272152964cb2314f0dff06562d4209daffdc7
mutation          the edited file swapped back to origin/main 9f3989771
                  markers: repaired-lines 0 (expect 0) · original-lines 2 (expect 2)
                  on-disk blob d30a8d7c… != HEAD blob  ⇒ the mutation is really on disk
rebuild proven    dist/index.js mtime 1788673935 -> 1788674362 (and index.d.ts 1788673952 -> 1788674379)
restore           blob 69c27215… == HEAD blob AND `git diff HEAD` empty; `git status --porcelain` empty
head rebuild      reproduces the pre-ablation dist BYTE-FOR-BYTE, 66/66 files

Result across the ablation:

• 0 of 22 published declaration files differ (dist/**/*.d.ts and *.d.mts, every
  entry point plus every subpath — apps, audit, identity, integration,
  metadata, metadata-translations, pages, plugin, security, system, root).
• 12 published files DID move in the same proven-rebuilt run: index.js, index.mjs,
  metadata-translations/index.js, metadata-translations/index.mjs, plugin.js,
  plugin.mjs and their six sourcemaps.
• Hunk classification on dist/metadata-translations/index.js: exactly 42 changed lines
  = the 21 pairs, every one a string-literal value. No declaration, no export, no
  signature. (esbuild emits the CJK as \uXXXX; two hunks switch the surrounding quote
  from " to ' because the value itself contains " — still a value.)

⇒ The declaration surface is provably still, while the runtime content provably moved. Per
the standing #16076 ruling, a string-literal VALUE inside an emitted data type is not limb-1
movement.

Changeset — patch, re-derived rather than taken

npm pack --dry-run --json in packages/platform-objects: not private, 69 entries, 66
dist/ files in the tarball and 0 src/ files; dist/index.js,
dist/metadata-translations/index.js, dist/plugin.js and dist/index.d.ts are all in it.
Scanning the 22 published JS files for each new value in its emitted \uXXXX form:
21 / 21 present, 6 files each, and the old action.fields.body value is present in 0.
⇒ Published content changes for a zh-reading Studio author ⇒ patch, ⛔ not skip-changeset.
No API surface moves ⇒ ⛔ not minor.

objectui overlay — checked per leaf, none of the 21 is shadowed

packages/app-shell/src/views/metadata-admin/metadata-form-i18n.ts at objectui
origin/main 3197379 resolves bundleLocale() to 'zh-CN' for zh, so a zh leaf CAN be
shadowed there. Its METADATA_FORM_BUNDLE declares exactly one type key — dashboard
(measured: 1 hit at the type indent, with a firing control returning 2 at the next indent
down). Every leaf this PR touches is under object, view, page, app, action,
report, email_template, permission or skill, so none of the 21 is shadowed, and
⛔ nothing in objectui is edited here. That is also why the five already-landed leaves were
the ones that needed overlay matching and these do not.

Reported, not repaired here

⚠️ The card's reading that "es-ES and ja-JP are correct for this class; zh-CN is alone"
was established at two leaves and does not generalise. Measured across the 21: es-ES and
ja-JP carry the same defect at nine of them, including the two the card singles out —
action.fields.body.helpText reads Código JavaScript que ejecutar / 「実行する JavaScript
コード」 in exactly the way zh-CN did. Filed separately with the table rather than widened
into here; ⛔ those files are also PR #16190's right now.

Related: #14587 (the census, comment 5524387962) · #14926 · #16163 · #16190.

🤖 Generated with Claude Code

https://claude.ai/code/session_01ARYe3yQTQCUFm5qPYNgKaJ

Generated by Claude Code